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POREVDRD 


Basically,  all  scientific  and  industrial  innovation  has  invariably 
been  a  semantic  clarification  of  a  certain  situation.  At  ESD,  in 
a  combined  1*07L  SPO-ESD-AFSC-DOD  value  engineering  effort,  something 
new  was  being  tried.  In  general,  the  effort  was  to: 

1.  Utilize,  in  every  stage  of  system  acquisition  from  con¬ 
cept  through  acquisition,  the  improved  cost  visibility  of  a  Value 
Engineering  Functional  Cost  Analysis  (VEFCA)  traditionally  used 
only  in  the  product  improvement  stage  of  system  acquisition. 

2.  Do  a  complete  System  Value  Engineering  task  on  a  highly 
complex  system  rather  than  merely  doing  "piece-meal"  value  engi¬ 
neering  of  components. 

Value  engineering  a  simple  product  requires  a  considerable  amount 
of  semantic  clarification.  The  more  precise  concept  of  value 
must  be  understood,  functions  must  be  defined  advantageously, 
and  the  many  steps  in  the  Value  Engineering  Job  Plan  must  be 
clarified.  Because  of  the  many  disciplines  involved,  the  prob¬ 
lem  becomes  much  more  complex  with  huge  systems. 

Much  of  this  paper  was  the  result  of  discussions  with  Mr.  Ray 
Gilbert  and  Mr.  Gordon  Frank,  members  of  the  DOD  Value  Engineering 
Office  who  participated  in  the  1*07L  effort.  Discussions  were  also 
held  with  Mr.  George  Allen  of  the  ESD  Technical  Requirements  and 
Standards  Office  and  ideas  were  solicited  from  members  of  the 
Boston  "Paul  Revere"  Chapter  of  the  Society  of  American  Value 
Engineers. 

The  author  appreciates  the  contributions  of  those  noted  above, 
but  assumes  all  responsibility  for  the  contents.  He  also  assumes 
that  creative  evaluation  of  this  paper  will  result  in  more  advanta¬ 
geous  clarifications  concerning  the  opportunities  inherent  in  the 
value  engineering  program. 


Review  and  Approval 
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ABSTRACT 


Advantageous  definitions  of  Value  Engineering  (VE) 3  the  "System 
Approach"  (SA),  System  Value  Engineering  (SVE),  the  Value  Engi¬ 
neering  Functional  Cost  Analysis  (VEFCA),  and  Traditional  Cost 
Analysis  (TCA)  are  given  to  simplify  discussion  and  communi¬ 
cations  and  stress  the  specific  actions  required  to  optimize 
the  value  of  military  systems.  Value  decision  making  is  also 
covered. 


SECTION  I 


PURPOSE 


1.  The  purpose  of  this  paper  is  to  advantageously  define  and 
clarify  the  differences  between  Value  Engineering  (VE)  and 
Cost  Effectiveness  (CE),  Value  Engineering  (VE)  and  System 
Value  Engineering  (SVE),  the  Value  Engineering  Functional  Cost 
Analysis  (VEFCA)  and  Traditional  Cost  Analysis  (TCA),  and 
Value  Engineering  at  different  levels  of  abstraction  in  order 
to: 


1.1  Simplify  discussion  and  communications. 

1.2  Utilize  the  improved  cost  visibility  of  the  VEFCA  in 
decision  making. 

1.3  Clarify  and  stress  the  specific  VE  actions  required  to 
improve  the  value  of  military  systems. 


SECTION  II 


ASSUMPTIONS 


2.1  The  semantic,  scientific,  and  value  engineering  assump¬ 
tions  upon  which  the  advantageous  definition  of  words  used  in 
a  value  engineering  (VE)  task  are  covered  in  Section  II, 
"Assumptions,"  of  "Advantageous  Definitions  Concerning  Value," 
ESD-TR-66-282,  dated  April  1966.  Other  assumptions  required 
by  the  purpose  of  this  paper  follow. 

2.2  Semantic  Assumptions:  Semantic  assumptions  required  by 
the  purpose  of  this  paper  follow: 

2.2.1  A  Word  Has  No  Meaning  By  Itself.  For  example,  in 
"A  sharp  soldier  sat  in  a  sharp  wind  cutting  sharp  cheese  with 
a  sharp  knife,"  the  word  sharp  has  four  different  meanings. 

2.2.2  Only  Relationships  Provide  Meaning.  "Sharp"  related 
to  "soldier"  means  one  thing,  but  "sharp"  related  to  "wind" 
means  another.  It  is  relationships  which  provide  meaning,  and 
the  history  of  science  indicates  that  relationships  between 
measurables  provide  the  most  advantageous  meanings. 

2.2.3  Functions  Provide  Meaningful  Relationships.  In  both 
mathematics  and  science,  functions  have  provided  advantageous 
meanings  because  they  indicated  a  relationship  between  a  demon¬ 
strable  operation  and  a  measurable  or  measurables. 

2.2.U  Levels  of  Abstraction  can  be  enumerated  as  follows: 


First  Level 


Second  Level 
Subsystems 


Third  Level 
Components 
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2.2.5  We  Abstract  By  Ignoring  Differences.  Joe  and  Jim 
have  sameness  and  differences.  We  ignore  their  differences 
(abstract),  move  up  the  ladder  of  abstraction,  and  call  each  a 
"man."  Likewise,  a  radio  and  radar  are  different,  but  we 
abstract  and  call  both  a  "component"  or  "system." 

2. 2.5.1  We  Abstract  In  Relation  To  Time.  An  RCA 
radio  in  19U0  was  different  from  an  RCA  radio  in  1966,  but  we 
abstract  and  say,  "RCA  radio."  This  can  lead  to  poor  evalua¬ 
tions. 


2. 2. 5. 2  We  Abstract  In  Relation  to  Tasks.  Reliability 
and  Configuration  Management  have  sameness  and  differences.  We 
ignore  differences  and  call  both,  "disciplines." 

2. 2.5.3  We  Abstract  In  Terms  Of  Any  Known  Differences, 
but  can  only  do  so  advantageously  when  the  resulting  abstractions 
contain  measurable  dimensions  which,  when  mathematically  manipu¬ 
lated,  can  still  be  related  directly  to  actuality. 

2.2.6  Multiordinal  words  are  abstractions  which  have  differ¬ 
ent  meanings  at  different  levels  of  abstractions;  i.e.,  in  the 
sentences,  "The  bracket  supports  weight,"  and  "The  United  States 
supports  the  United  Nations,"  the  word  "supports"  has  different 
meanings. 


2. 2.6.1  Note.  Failure  to  note  that  words  such  as 
"value  engineering,"  "cost  effectiveness,"  etc.,  have  different 
meanings  at  different  levels  of  abstraction  is  the  basis  for 
much  linguistic  confusion  in  system  acquisition  discussions. 

2.2.7  Notation.  Korzybski,  in  his  book,  "Science  and  Sanity," 
has  stressed  the  value  of  annotating  words  to  indicate  that  they 
are  being  used  at  a  different  level  of  abstraction  or  are  multi¬ 
ordinal;  i.e.,  supports^  -  meaning  "support  used  on  the  top  level 
of  abstraction"  -  is  not  the  same  as  support 2  -  "support  used  on 
the  second  level  of  abstraction. " 
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SECTION  III 


DEFINITIONS  AND  NOTATION 


3.1  Because  of  the  assumptions  of  Section  II,  it  is  deemed  advanta 
geous  to  define  the  following  words  as  follows: 

3.1.1  A  function  is  a  meaningful  relationship  indicated  by  a 
verb  and  a  noun. 

3.1.2  A  verifiable  function  is  a  relationship  between  a  demon 
strable  verb  and  a  measurable  or  countable  noun;  i.e.,  "supports/ 
weight, "  "transmits7bits. " 

3.1.3  An  operational  requirement  is  a  functional  need  or 
needs.  Examples  are  "provide/communications,"  "provide/fighter 
cover,"  "move/weight,"  "provide/deterrence."  An  operational 
requirement  as  first  defined  may  or  may  not  be  verifiable.  For 
instance,  "provide/deterrence, "  is  not  verifiable  since  deterrence 
cannot  be  realistically  measured  in  advance.  It  is  part  of  the 
value  engineering  task  to  redefine  and  reduce  operational  require¬ 
ments  which  are  not  verifiable  to  verifiable  functions. 

3.1.1;  A  basic  function  is  a  verifiable  function  which  most 
advantageously  defines  the  value  engineering  task.  It  should  be 
realized  that  a  basic  function  rarely  defines  all  the  opera¬ 
tional  requirements.  For  instance,  the  advantageous  definition 
of  many  weapon  systems  is  "moves/weight."  A  weapon  system  must 
also  "provide/destruction,"  and  "pinpoint/target, "  but  with 
most  weapon  systems  moving  weight  is  its  most  costly  function. 

A  land  mine  may  seem  an  exception,  yet  its  advantageously  defined 
function  is  only  more  specific;  i.e.,  "move/hard  bits  of  weight 
suddenly. " 

3.1.5  A  secondary  function  is  a  verifiable  function  on  the 
same  level  of  abstraction  as  the  basic  function  which  is  not 
required  by  the  basic  function,  but  is  required  by  the  opera¬ 
tional  requirement;  i.e.,  the  basic  function  of  a  pencil  is  to 
"make/marks,"  a  secondary  function  is,  "erase/marks. "  Like¬ 
wise,  the  basic  function  of  a  car  is  to  "move/weight, "  while 
secondary  functions  are,  "provide/comfort,"  "provide/safety," 
"provide/esteem. " 

3.1.6  A  supporting  function  is  a  verifiable  function  on 
levels  of  abstraction  below  a  basic  or  secondary  function  and 
without  which  the  operational  requirement  cannot  be  fulfilled 
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except  at  excessive  cost;  i.e.,  the  basic  function  of  a  bomber 
is  advantageously  defined  as,  "moves/weight."  A  supporting 
function  to  the  performance  of  moving  weight  is  "pinpoint/ 
destination."  However,  a  bomber  has  a  secondary  function  of 
"provide/destruction,"  and  that  secondary  function  has  supporting 
functions  such  as  "release/bomb,"  "pinpoint/target,"  etc. 

3.2  To  eliminate  confusion  concerning  levels  of  abstraction  and 
the  multiordinal  aspects  of  the  verb  value  engineer,  it  is  deemed 
advantageous  to  define  value  engineering  and  use  notation  as 
follows: 

3.2.1  To  value  engineer  in  general  is  to: 

3. 2.1.1  Define  required  functions  advantageously. 

3. 2. 1.2  Determine  supporting  functions  which  will 
provide  those  required  functions  at  the  least  cost. 

3.2.2  Value  Engineering^  (VE!)  the  required  function 
(basic  or  secondary)  at  the  first  level  determines  the  many  ways 
of  performing  that  function,  and  the  cost  of  those  ways;  i.e., 
if  the  basic  function  is  "moves/weight, "  VE^  determines  the  many 
ways  of  moving  weight  such  as  by  jet,  train,  truck,  boat,  or 
pipeline,  and  each  way's  ton-miles  per  hour  per  dollar. 

3.2.3  Value  Engineering2  (VE2)  the  required  function  at 
the  second  level  determines  and  costs  the  supporting  functions 
of  one  way  of  performing  the  basic  function;  i.e.,  if  the  basic 
function  is  moves/weight,  VE^  determines  and  costs  the  supporting 
functions  of  a  plane  or  a  truck  or  a  pipeline. 

3.2.1;  Value  Engineering!* 2  (ve!*^)  .^e  reqUj_recj  function 
at  the  first  and  second  level  determines  and  costs  all  ways  of 
performing  the  function  and  also  determines  and  costs  the  second 
level  supporting  functions  of  all  ways  of  performing  the  required 
function. 

3.2.5  Value  Engineering'*-* ^  (VE-*-*^)  the  required  function 
in  depth  to  the  Nth  level  determines  and  costs  all  ways  of 
performing  all  required  functions  down  to  and  including  the  Nth 
level. 


3.3  To  advantageously  define  from  a  value  viewpoint,  abstrac¬ 
tions  used  in  system  acquisition,  the  following  definitions 
are  recommended: 

3.3.1  A  system  is  a  group  of  verifiable  functions  required 
to  provide  a  group  of  operational  requirements. 
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3*3*2  The  "System  Approach"  (SA)  is  a  process  or  procedure 
which  considers  whether  more  operational  requirements  can  be 
fulfilled  by  a  system  without  adding  prohibitive  costs.  SA 
"broadens  the  scope,"  reviews  all  operational  requirements  and 
their  required  verifiable  functions  in  order  to  ascertain  one 
optimum  system  which  will  provide  the  greatest  number  of 
operational  requirements  at  the  least  cost. 

3*3*3  It  should  be  noted  that,  although  value  engineers 
sometimes  use  the  Systems  Approach  while  attempting  to  define  the 
required  functions,  in  general,  their  improved  cost  visibility 
is  the  result  of  value  engineering  in  depth  and  placing  costs 
upon  alternate  ways  of  performing  supporting  functions;  i.e., 
value  engineers  usually  move  down  the  ladder  of  abstraction. 

3*3*U  In  contrast  with  value  engineering,  the  SA  moves  up 
the  ladder  of  abstraction  including  more  operational  require¬ 
ments  in  every  step  up.  An  example  follows: 

3* 3*^*1  Assume  at  first  that  the  system  includes 
only  on-base  teletype  distribution  requirements. 

3*3*i+.2  The  system  is  broadened  to  include  all  on- 
base  data  transmission  requirements  including  the  teletype 
requirement  and  logistic  and  personnel  statistical  control. 

3.3. U.3  The  system  is  broadened  again  to  include 
other  operational  requirements  such  as,  "type/letters,"  thus, 
utilizing  an  IBM  Selectric  typewriter  which  can  both  "type/ 
letters,"  and  serve  as  a  data-transmission  input/output  device. 

3.3>h.h  The  system  is  further  broadened  to  "handle/ 
information,"  which  includes  all  above,  plus  automation  require¬ 
ments  such  as  water  distribution  pump  control,  sewer  pump  control, 
aircraft  generation  data  distribution  and  display. 

3.3. U.5  The  power  of  the  SA  is  that  it  ignores  passe 
solutions,  thinks  in  terms  of  functional  requirements,  and  con¬ 
siders  many  more  creative  alternatives  and  especially  ways  of 
combining  required  functions  advantageously. 

3*U  System  Value  Engineering  (SVE).  It  is  possible  and  advanta¬ 
geous  to  define  SVE,  in  general,  as  an  optimum  approach  which 
combines  both  the  Value  Engineering  (VEIjN)  approach  and  the 
System  Approach  (SA).  Further,  this  SVE  approach  can  be  more 
specifically  defined  as  doing  the  following: 

3 * U . 1  Considers  the  system  as  a  whole;  i.e.,  considers 
all  possible  operational  requirements  which  might  be  provided 
by  the  system. 
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3 . U- U  Develops  a  family  tree  of  required  functions  (ladder 
of  abstraction)  and: 

3.1|.li.l  Places  a  Cost  Target,  Cost  Standard,  and/or 
a  Cost-To-Standard  Ratio  on  the  highest  level  of  verifiable  func¬ 
tions;  i.e.,  it  does  not  merely  place  costs  upon  higher  level  opera¬ 
tional  requirements  which  cannot  be  stated  in  verifiable  func¬ 
tions. 


3.1*.U.2  Integrates  outputs  from  operational  analysis, 
system  cost  effectiveness,  reliability  cost  effectiveness,  main¬ 
tainability  cost  effectiveness  which  are  actually  Value  Engineering-*- 
(VEl)  at  one  specified  level  of  abstraction. 

3.b-h'3  Value  Engineers**-^  (VE-^^)  xn  greater  func¬ 
tional  depth  as  system  acquisition  progress  from  system  concept, 
system  definition,  etc. 

3. 1;.5  Avoids  traditional  System  Engineering  (SE)  practices 
which  are  detrimental  to  system  value.  In  practice,  SE  has 
traditionally  broken  the  task  of  producing  a  system  down  into 
subsystems  and  assigned  different  groups  of  engineers  (some¬ 
times  different  corporations)  the  task  of  producing  each  sub¬ 
system.  Another  group  of  "interface"  engineers  (or  the 
Integrating  Engineer)  is  given  the  task  of  making  sure  those 
subsystems  will  work  together.  This  means  different  groups 
of  people  isolated  from  each  other,  make  value  decisions  on 
the  same  level  of  abstraction,  but  in  different  subsystems 
which  would  be  highly  apt  to  be  better  decisions  if  made 
together  by  all  groups  or  by  a  Value  Team  considering  several 
levels  of  abstraction  straight  across  all  subsystems;  i.e., 
if  the  subsystem  is  level  2,  a  VE2j3j4  or  VE^>3,4,5  study  of 
all  subsystems  would  be  made  which  would  eliminate  redundant 
functions  (functions  unnecessarily  duplicated  in  each  sub¬ 
system)  and/or  improve  reliability  without  providing  excessive 
redundancy. 


3.5  The  Value  Engineering  Functional  Cost  Analysis  (VEFCA). 

It  is  possible  and  advantageous  to  define  the  VEFCA,  in  general, 
as  a  family  tree  of  functions  (ladder  of  abstraction)  which 
reveals  the  required  verifiable  functions  of  a  system  and  their 
costs.  Further,  it  is  deemed  advantageous  to: 


3.5.1  Annotate  each  VEFCA  with  numbers  as  in  VE-*-,  VE^, 
etc.,  to  indicate  on  what  levels  of  abstraction  that  VEFCA  has 
determined  functions  and  their  costs;  i.e.,  a  VEFCA-*-^  WOuld 
be  the  result  of  VE-*-^. 


3.5.2  Keep  the  system  equipment  functions  and  acquisition 
costs  separate  from  the  system  data  acquisition  costs;  i.e.. 
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develop  a  VEFCA  for  system  equipment  and  another  VEFCA  for  system 
data.  (This  does  not  mean  the  of  equipment  ignores  data 

costs. ) 


3.5.3  Realize  how  the  VEFCA  differs  from  Traditional  Cost 
Analysis  (TCA)  in  that: 

3. 5. 3*1  The  VEFCA  utilizes  TCA,  but  adds  to  it  and 
improves  cost  visibility  because  it  does  add  to  it. 

3.5.3. 2  TCA  obtains  all  the  organizational  costs 
which  pertain  to  the  total  costs  of  a  product  at  a  specified 
level  of  abstraction,  but  does  not  specify  the  functions  and 
their  costs  of  that  product.  See  Chart  1  for  a  simplified 
example . 


3. 5. 3. 3  A  VEFCA  obtains  all  the  organizational 
costs  which  pertain  to  each  function  of  a  product.  See  Chart  2 
for  a  simplified  example. 

3«5«U  Note  how  Value  Engineering  can  exploit  the  creative 
principle  of,  "Defer  Judgment,"  by  not  making  a  decision 
concerning  how  to  perform  a  function  on  one  specified  level 
until  the  costs  of  supporting  functions  are  ascertained;  i.e., 

TCA  bases  decisions  on  the  cost-functional  relationship  at 
one  level  of  abstraction  while  VE  considers  the  function-cost 
relationship  at  several  levels  of  abstraction  before  making 
decisions. 

3.5.5  Note  that  VE  places  a  cost  on  a  function,  (an  opera¬ 
tional  requirement)  rather  than  upon  a  thing  (component)  which 
too  often  is  a  passe  solution  rather  than  a  requirement. 

3.5.6  Note  that  a  VEFCA  is  multiordinal  in  relation  to  time; 
i.e.,  a  VEFCA  of  the  same  equipment  is  not  the  same  in  1966  as  in 
1967.  For  instance,  the  VEFCA66  may  contain  estimated  cost  targets 
while  the  VEFCA67  may  contain  actual  costs. 

3.6  It  is  deemed  advantageous  to  develop  a  separate  VEFCA  for 
data  alone.  There  are  several  reasons  for  this.  First,  it  is 
assumed  that  the  basic  function  of  a  SVE  task  is  to  "product/ 
system  (equipment)  value."  It  is  a  secondary,  but  essential  task 
to  "provide/system  data  value."  Later,  it  will  be  discussed 
how  these  two  VEFCAs  must  be  related.  Second,  the  value  engi¬ 
neering  of  equipment  is  basically  different,  and  it  is  deemed 
advantageous  to  apply  the  creative  principle  of  "divide  and 
conquer"  to  them.  The  differences  in  VE  equipment  and  VE  data 
follow: 

3.6.1  The  VE  of  equipment  is  one  task  which  relates  equip¬ 
ment  functions  directly  to: 
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3. 6. 1.1  The  organizational  costs,  (engineering, 
development,  production,  reliability,  test  transportation, 
overhead,  etc.,  costs)  which  product  each  function. 

3.6.1. 2  Data  costs  which  become  necessary  because 
that  equipment  function  (or  functions)  is  produced. 

3. 6. 1.3  Logistic  and  operational  costs  which  become 
necessary  because  that  function  (or  functions)  is  produced. 

3.6.2  The  VE  of  data  consists  of  two  VE  tasks  unrelated 
cost-wise  as  follows: 

3. 6. 2.1  The  value  engineering  of  information  pre¬ 
sentation  including: 


3.6. 2. 1.1  The  physical  data  materials  (paper, 
microfilm,  etc.,)  which  display  the  required  information. 

3. 6. 2. 1.2  The  reproduction  means  of  placing 
the  required  information  on  the  data  material. 

3.6. 2. 1.3  The  economic  layout  of  the 
required  information  on  the  data  material. 

3. 6. 2. 2  The  value  engineering  of  information  develop¬ 
ment  including: 


3.6. 2. 2.1 
3.6. 2. 2. 2 

keep  statistics,  etc. 

3. 6. 2. 2. 3 

3.6.2.2.U 

the  information. 


Manhours  of  engineering,  etc. 
Computer  costs  to  solve  problems, 

Record  keeping. 

An  evaluation  of  the  need  for 
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SECTION  IV 


CORRELATIONS 


li.l  System  acquisition  is  a  complex  task  of  coordinating  the 
actions  of  many  disciplines.  Further,  most  specialists  speak 
a  language  of  their  own  and  use  certain  key  words  differently. 
The  purpose  of  this  section  is  to  clarify  the  use  of  certain 
key  words  and  phrases  used  differently  by  various  disciplines. 

U.2  The  Total  Package  Procurement  Concept  (TPPC)  is  a  pro¬ 
cedure  for  placing  all  costs  considered  by  a  System  Value 
Engineering  effort  under  one  contract  to  the  degree  practical. 
However,  this  does  mean  that  every  SVE  should  or  does  result 
in  a  TPPC  contract. 

h.3  AFSCL  173-1?  "Cost  Estimating  Procedures,"  October  1965} 
reveals  that: 

ii.3.1  The  word  "function"  or  "functional"  usually  refers 
to  an  organizational  function;  i.e.,  to  departments  such  as, 
"engineering,  tooling,  quality  control,"  etc.,  and  rarely 
refers  -  if  at  all  -  to  product  function. 

H.3.2  "Functional  costs"  refer  to  organizational  depart¬ 
ment  costs  and  not  to  product  function  costs  as  used  by  value 
engineers. 

U. 3 - 3  Level  U,  "The  Work  Breakdown  Structure,"  (WBS)  is 
an  attempt  to  deal  with  the  "physical  work  performed"  as  the 
manual  on  page  2— U  states.  However,  that  level  actually  names 
a  system  such  as  Missile,  Aircraft,  Command  &  Control  and  can, 
therefore,  be  considered  level  1  of  a  VEFCA. 

Iu3»U  For  all  practical  purposes,  levels  U,  5}  6,  and  7 
referred  to  in  AFSCL  173-1  are  the  same  levels  of  abstraction 
as  levels  1,  2,  3,  and  U  of  a  system  VEFCA  since  they  refer 
to  systems,  subsystems,  components  and  subcomponents.  How¬ 
ever,  those  levels  are  indicated  by  the  name  of  the  system, 
subsystem,  etc.,  rather  than  by  the  advantageously  defined 
function  it  provides. 

U.3.5  According  to  Figure  3-2  on  page  3-13,  the  func¬ 
tional  levels  below  level  7  refer  to  organizational  functions 
(departments)  and  not  to  system  equipment  functions. 
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ii.il  Traditionally,  any  Cost  Effectiveness  Study  is  the  same 
as  a  Value  Engineering  (VE-*-)  at  one  level  of  abstraction 
while,  traditionally,  any  Value  Engineering  study  considers 
several  levels  of  abstraction;  i.e.,  are  VE^^  efforts.  This 
VE-*-’^  results  in  a  vastly  improved  cost  visibility. 

1;.5>  Traditionally,  "Reliability  Costs,"  refer  to  "Staff 
Reliability  Costs;"  that  is,  to  costs  generated  by  Reliability 
specialists  and  reliability  testing.  However,  in  Value  Engi¬ 
neering,  where  a  cost  is  placed  on  every  function,  those 
functions  which  contribute  to  structural  and/or  electronic 
reliability  can  be  annotated  and,  "Product  Reliability  Costs," 
can  be  thus  more  realistically  estimated. 

1*.6  Traditionally,  the  VEFCAIjN  has  been  used  during  product 
improvement.  However,  herein,  it  is  assumed  that  the  improved 
cost  visibility  of  the  VEFCA  can  be  profitably  used  from  con¬ 
cept  to  grave  and,  especially,  during  design  reviews. 

U.7  Traditionally,  costs  have  been  placed  upon  "things."  This 
resulted  in  a  complex,  three-part  contingency  in  which  costs 
were  related  to  things  and  functions  were  related  to  things, 
but  costs  were  not  related  directly  to  functions.  In  VE, 
costs  are  related  to  functions.  This  has  two  advantages  as 
follows: 

U.7.1  Operational  requirements  are  stated  in  functional 
terms  and  can  be  more  realistically  estimated  if  function  costs 
are  known. 

U.7.2  There  are  millions  of  "things"  in  the  Air  Force 
inventory,  but  less  than  I4.OO  known  functions.  If  function  costs 
were  used,  the  search  and  retrieval  problem  of  cost  estimating 
would  be  drastically  reduced. 

U . 8  To  advantageously  correlate  required  cost  information, 
four  ladders  of  abstraction  should  be  considered. 

li.u.l  The  VEFCA  of  the  system  equipment  herein  indicated 
as  the  SE  VEFCA.  (Simplified  example,  Attachment  #1) 

11.8.2  The  VEFCA  of  the  system  data.  For  practical  pur¬ 
poses,  this  is  the  Data  List  plus  costs.  For  value  engineering 
purposes,  computer  programing  is  considered  data. 

11.8.3  The  Table  of  Organization  of  the  concern  producing  the 
system  and  which  generates  all  acquisition  costs  except  other 
government  costs  outside  the  contract. 

U • 8 . U  Operational  and  Logistic  Costs 
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U.9  Unfortunately,  traditional  cost  analysis  (TCA)  does  not 
provide  a  direct  one-to-one  correspondence  between  all  the 
functions  in  the  four  ladders  of  abstraction  of  U.8  except  at 
some  high  levels  of  abstraction.  Nor  does  value  engineering. 
However,  with  value  engineering,  we  move  from  a  poor  correlation 
to  a  better  correlation,  from  inadequate  cost  visibility  to  a 
better  cost  visibility,  to  less  one-to-one  correspondence  to  more. 

U.10  Normally,  there  is  a  one-to-one  correspondence  between 
Contract  End  Items  (CEI)  (Level  6  -  WBS  in  AFSCL  173-1),  and 
the  total  organizational  costs  involved  in  providing  those  Con¬ 
tract  End  Items  (except  for  government  furnished  CEIs  in  the 
system. )  However,  there  is  no  one-to-one  correspondence  between 
the  functions  in  each  CEI  and  the  cost  connected  with  each 
function  of  each  CEI.  For  this  reason,  the  costs  of  redundant 
and  excessively  costly  functions  are  not  visible. 

lull  The  degree  to  which  correlations  are  made  between  these 
four  ladders  of  abstraction  is  actually  a  matter  of  value  engi¬ 
neering  judgment.  For  instance,  it  is  rarely  practical  to 
correlate  low-level  component  functions  with  the  data  those 
low-level  functions  generate.  However,  evaluations  considering 
component  changes  should  consider  the  impact  of  those  changes 
on  data  costs  as  well  as  upon  operational  and  logistics  costs. 
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SECTION  V 


VALUE  DECISION  MAKING 


5.1  Value  decisions  in  modern  organizations  are  made  by  many 
highly  trained  specialized  people  at  all  levels  of  the  organiza¬ 
tion.  However,  most  of  the  decisions  which  cause  costs  are  made 
at  lower  levels  or  are  based  upon  lower  level  recommendations. 
Further,  most  such  decisions  are  made  in  isolation,  and  people 
making  them  do  not  have  access  to  information  which  reveals  the 
impact  of  those  decisions  upon  acquisition  cost  much  less  total 
costs.  In  fact,  many  specialists  by  regulation  and  directives 
are  forced  to  place  military  specifications  upon  systems  without 
having  access  to  information  which  indicates  the  impact  upon 
total  system  costs  of  that  specification.  Usually,  they  try 

to  generalize  too  much  (not  tie  people  down)  and  such  generaliza¬ 
tions  often  cause  unnecessary  costs.  For  instance,  one  specifica¬ 
tion  in  a  military  system  called  for  a  circuit  current  from  $Oma 
to  1  ampere.  Thousands  of  diodes  were  involved.  A  reliable  50ma 
diode  cost  at  that  time  15>0.  A  reliable  one  amp  diode  cost  over 
$2.00.  For  some  reason,  perhaps  because  it  was  a  Cost  Plus 
Contract,  the  contractor  thought  the  Air  Force  should  have  the 
one  amp  diode. 

5.2  Basically,  the  purpose  of  a  SVE  task  is  to  provide  an 
improved  cost  visibility  which  allows  system  decision  makers 
to  make  better  value  decisions;  i.e.,  obtain  verifiable  func¬ 
tions  for  less  cost.  It  is  the  VEFCA  which  should  provide 
that  cost  visibility. 

5.3  Ideally,  no  value  decisions  would  be  made  until  a  SVE-*-’^ 
task  was  completed  in  infinite  detail  down  to  very  low  functional 
detail  (N  would  be  a  large  number).  Time  makes  such  an  ideal 
highly  impractical  although  in  the  future  realistic  Value  Standards 
and  computer  techniques  (a  modified  Critical  Path  Method,  for 
instance)  will  come  closer  to  that  ideal.  The  question  is,  of 
course,  how  large  should  N  be?  How  far  below  Traditional  Cost 
Analysis  should  the  VEFCA  go  to  improve  cost  visibility  to  a 
practical  degree?  This,  again,  is  a  matter  of  value  engineering 
judgment,  but  some  guidance  can  be  provided. 

5.U  One  fact  is  immediately  obvious.  To  improve  cost  'visibility, 
a  VEFCA  must  go  below  the  level  at  which  TCA  now  places  a  cost 
for  the  Air  Force.  This  is  usually  at  the  component  or  the 
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Contract  End  Item  level.  Second,  it  would  be  impractical  to 
value  engineer  and  improve  the  cost  visibility  of  those  com¬ 
ponents  which  cost  only  a  small  percent  of  the  system.  The 
VEFCA  must  improve  the  cost  visibility  where  the  high  costs 
occur.  It  must  not  be  overlooked,  however,  that  some  component 
functions  may  cost  only  a  small  percent  of  small-cost  components, 
but  becuase  they  are  repeated  again  and  again  across  the  system 
add  up  to  a  considerable  percent  of  system  costs. 

5.5  The  next  obvious  question  is,  "How  far  below  the  TCA  must 
the  VEFCA  go?"  The  specific  answer  is  again  a  matter  of  value 
engineering  judgment  since  it  will  vary  function  by  function 
depending  upon: 

5.5.1  What  percent  of  the  component  cost  that  function 
costs. 

5.5.2  To  what  degree  the  function  is  repeated  across  the 
system. 

5.5.3  To  what  degree  modification  of  the  function  would 
have  upon  reliability,  other  desired  system  characteristics,  and 
operational  and  logistic  costs . 

Note :  In  one  VE  training  session,  it  was  noted  that  17#  of  the 
costs  of  a  small  component  part  was  connector  costs  while  83#  was 
a  specific  logic  circuit.  Naturally,  the  Value  Team  was  interested 
in  the  83#  until  it  was  pointed  out  that  the  connector  costs 
could  obviously  be  cut  in  half  and  since  the  connectors  were  not 
only  standard  in  the  division  for  all  components,  but  standard 
across  all  divisions  of  the  corporation  while  the  logic  part 
was  not,  the  greatest  savings  would  occur  by  value  engineering 
the  connectors. 

5.6  Most  important  to  value  decision  making  is  the  fact  that  the 
improved  cost  and  function  visibility  provided  by  the  VEFCA  allows 
the  creative  principles  of  "Defer  Judgment,  Quantity  Breed  Quality, 
etc.,"  to  be  used  since,  with  several  levels  of  abstractions  being 
considered  rather  than  just  one,  many  more  possibilities  can  be 
considered. 

5-7  Actually,  value  decisions  cannot  be  optimized  in  traditional 
organization  without  doing  something  different  than  normal  since 
modern  organization  with  its  split  capabilities,  split  responsibilities 
and  split  authority  is  very  effectively  structured  to  cause  unneces¬ 
sary  costs.  With  everyone  responsible  for  value,  no  one  is.  To 
correct  this,  the  top  manager  must  be  very  value  conscious,  aware 
of  the  organizational  discrepancies  which  cause  unnecessary  costs 
and  how  people  must  be  organized  to  provide  a  VEFCA  whose  improved 
cost  visibility  allows  better  value  decisions.  The  steps  required 
to  value  engineer  and  manage  value  are  found  in,  "Advantageous 
Definitions  Concerning  Value." 
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